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Abstract

   This document allocates the fixed pseudowire identifier and other
   fixed protocol values for protocols that have been defined in the
   Pseudo Wire Edge to Edge (PWE3) working group.  Detailed IANA
   allocation instructions are also included in this document.
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1.  Introduction

   Most of the new IANA registries and respective IANA-allocation
   processes for protocols defined in the PWE3 IETF working group can be
   found in this document.  The IANA registries defined here are in
   general subdivided into three main ranges: a range to be allocated by
   IETF consensus according to [RFC2434], a range to be allocated by the
   expert review process according to [RFC2434], and a range to be
   allocated on a first come, first served basis that is reserved for
   vendor proprietary allocations.  Note that vendor proprietary types
   MUST NOT be registered for IETF standards or extensions thereof,
   whether they are still in development or already completed.

2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  IANA Considerations

   IANA has created several registries as described in the following
   paragraphs.  Each of these registries contains numeric values used to
   identify data types.  In each of these registries, the value of 0 is
   reserved and MUST not be used.

3.1.  Expert Review Directives

   Throughout this document, allocation procedures for several
   registries call for an expert review process according to [RFC2434].
   The expert should consider the following points:

      *  Duplication of code point allocations should be avoided.

      *  A brief, clear description of the code point allocation
         requested should be provided.

      *  The type allocation requested should be appropriate for the
         particular requested value range in the registry.

   The expert reviewing the request MUST approve or disapprove the
   request within 10 business days from when he or she received the
   expert review request.
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3.2.  MPLS Pseudowire Type

   IANA has set up the registry of "MPLS Pseudowire Type".  This type
   has 15-bit values.  PW Type values 1 through 30 are specified in this
   document, and PW Type values 31 through 1024 are to be assigned by
   IANA, using the "Expert Review" policy defined in [RFC2434].  PW Type
   values 1025 through 4096 and 32767 are to be allocated using the IETF
   consensus policy defined in [RFC2434].  PW Type values 4097 through
   32766 are reserved for vendor-proprietary extensions and are to be
   assigned by IANA, using the "First Come First Served" policy defined
   in [RFC2434].  A Pseudowire Type description is required for any
   assignment from this registry.  Additionally, for the vendor-
   proprietary extensions range, a citation of a person or company name
   is also required.  A document reference should also be provided.

   Initial Pseudowire Type value allocations are specified below:

   PW type Description                                      Reference
   ===================================================================
   0x0001  Frame Relay DLCI ( Martini Mode )                [FRAME]
   0x0002  ATM AAL5 SDU VCC transport                       [ATM]
   0x0003  ATM transparent cell transport                   [ATM]
   0x0004  Ethernet Tagged Mode                             [ETH]
   0x0005  Ethernet                                         [ETH]
   0x0006  HDLC                                             [PPPHDLC]
   0x0007  PPP                                              [PPPHDLC]
   0x0008  SONET/SDH Circuit Emulation Service Over MPLS    [CEP]
   0x0009  ATM n-to-one VCC cell transport                  [ATM]
   0x000A  ATM n-to-one VPC cell transport                  [ATM]
   0x000B  IP Layer2 Transport                              [RFC3032]
   0x000C  ATM one-to-one VCC Cell Mode                     [ATM]
   0x000D  ATM one-to-one VPC Cell Mode                     [ATM]
   0x000E  ATM AAL5 PDU VCC transport                       [ATM]
   0x000F  Frame-Relay Port mode                            [FRAME]
   0x0010  SONET/SDH Circuit Emulation over Packet          [CEP]
   0x0011  Structure-agnostic E1 over Packet                [SAToP]
   0x0012  Structure-agnostic T1 (DS1) over Packet          [SAToP]
   0x0013  Structure-agnostic E3 over Packet                [SAToP]
   0x0014  Structure-agnostic T3 (DS3) over Packet          [SAToP]
   0x0015  CESoPSN basic mode                               [CESoPSN]
   0x0016  TDMoIP AAL1 Mode                                 [TDMoIP]
   0x0017  CESoPSN TDM with CAS                             [CESoPSN]
   0x0018  TDMoIP AAL2 Mode                                 [TDMoIP]
   0x0019  Frame Relay DLCI                                 [FRAME]
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3.3.  Interface Parameters Sub-TLV Type

   IANA has to set up the registry of "Pseudowire Interface Parameter
   Sub-TLV types".  This type has 8-bit values.  Sub-TLV types 1 through
   12 are specified in this document.  Sub-TLV types 13 through 64 are
   to be assigned by IANA, using the "Expert Review" policy defined in
   [RFC2434].  Sub-TLV types 65 through 127 and 255 are to be allocated
   using the IETF consensus policy defined in [RFC2434].  Sub-TLV types
   values 128 through 254 are reserved for vendor-proprietary extensions
   and are to be assigned by IANA, using the "First Come First Served"
   policy defined in [RFC2434].

   Any assignments requested from this registry require a description of
   up to 54 characters.

   For each allocation, a length field MUST also be specified in one of
   the following formats:

      -  Text as follows:"up to X", where X is a decimal integer.
      - Up to 3 different decimal integers.

   The text "up to X" means up to and including X.

   Additionally, for the vendor-proprietary extensions range, a citation
   of a person or company name is also required.  A document reference
   should also be provided.

   Initial Pseudowire Interface Parameter Sub-TLV type allocations are
   specified below:

Parameter  Length       Description                       Reference
 ID
========================================================================
 0x01      4       Interface MTU in octets               [CRTL]
 0x02      4       Maximum Number of concatenated ATM cells [ATM]
 0x03   up to 82   Optional Interface Description string [CRTL][RFC2277]
 0x04      4       CEP/TDM Payload Bytes                 [CEP][TDMoIP]
 0x05      4       CEP options                           [CEP]
 0x06      4       Requested VLAN ID                     [ETH]
 0x07      6       CEP/TDM bit-rate                      [CEP][TDMoIP]
 0x08      4       Frame-Relay DLCI Length               [FRAME]
 0x09      4       Fragmentation indicator               [FRAG]
 0x0A      4       FCS retention indicator               [FCS]
 0x0B    4/8/12    TDM options                           [TDMoIP]
 0x0C      4       VCCV parameter                        [VCCV]

   Note that the Length field is defined as the length of the Sub-TLV,
   including the Sub-TLV type and length field itself.
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3.4.  Attachment Identifiers

3.4.1.  Attachment Individual Identifier Type

   IANA has to set up the registry of "Attachment Individual Identifier
   (AII) Type".  This type has 8-bit values.  AII Type value 1 is
   defined in this document.  AII Type values 2 through 64 are to be
   assigned by IANA, using the "Expert Review" policy defined in
   [RFC2434].  AII Type values 65 through 127 and 255 are to be
   allocated using the IETF consensus policy defined in [RFC2434].  AII
   types values 128 through 254 are reserved for vendor-proprietary
   extensions and are to be assigned by IANA, using the "First Come
   First Served" policy defined in [RFC2434].

   Any assignments requested from this registry require a description of
   up to 54 characters.

   For each allocation, a length field MUST also be specified as a
   decimal integer.

   Additionally, for the vendor-proprietary extensions range, a citation
   of a person or company name is also required.  A document reference
   should also be provided.

   Initial Attachment Individual Identifier (AII) Type allocations are
   specified below:

   AII Type     Length    Description                          Reference
   =====================================================================
   0x01         4         A 32 bit unsigned number local       [SIG]
                          identifier.

3.4.2.  Attachment Group Identifier (AGI) Type

   IANA has to set up the registry of "Attachment Group Identifier (AGI)
   Type".  This type has 8-bit values.  AGI Type value 1 is defined in
   this document.  AGI Type values 2 through 64 are to be assigned by
   IANA, using the "Expert Review" policy defined in [RFC2434].  AGI
   Type values 65 through 127 and 255 are to be allocated using the IETF
   consensus policy defined in [RFC2434].  AGI type values 128 through
   254 are reserved for vendor-proprietary extensions and are to be
   assigned by IANA, using the "First Come First Served" policy defined
   in [RFC2434].

   Any assignments requested from this registry require a description of
   up to 54 characters.
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   For each allocation, a length field MUST also be specified as a
   decimal integer.

   Additionally, for the vendor-proprietary extensions range, a citation
   of a person or company name is also required.  A document reference
   should also be provided.

   Initial Attachment Group Identifier (AGI) Type allocations are
   specified below:

   AGI Type     Length    Description                        Reference
    ===================================================================
    0x01         8         AGI encoded as Route Distinguisher [SIG]

3.5.  Pseudowire Status

   IANA has to set up the registry of "Pseudowire Status Codes".  These
   are bit strings of length 32.  Status bits 0 through 4 are defined in
   this document.  Status bits 5 through 31 are to be assigned by IANA
   using the "Expert Review" policy defined in [RFC2434].

   Any requests for allocation from this registry require a description
   of up to 65 characters.

   Initial Pseudowire Status Code value allocations are as follows:

   Bit Mask     Description
   ====================================================================
   0x00000000 - Pseudowire forwarding (clear all failures)       [CRTL]
   0x00000001 - Pseudowire Not Forwarding                        [CRTL]
   0x00000002 - Local Attachment Circuit (ingress) Receive Fault [CRTL]
   0x00000004 - Local Attachment Circuit (egress) Transmit Fault [CRTL]
   0x00000008 - Local PSN-facing PW (ingress) Receive Fault      [CRTL]
   0x00000010 - Local PSN-facing PW (egress) Transmit Fault      [CRTL]

   For the definition of the "PW Associated Channel Type" please refer
   to [RFC4385].

3.6 PW Associated Channel Type

   For the definition of the "PW Associated Channel Type", please refer
   to [RFC4385].
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4.  Security Considerations

   This document specifies only fixed identifiers, and not the protocols
   used to carry the encapsulated packets across the network.  Each such
   protocol may have its own set of security issues, but those issues
   are not affected by the identifiers specified herein.
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